Page history of 개발자 채용

내가 개발자를 채용해야 할 때 중요하게 생각하는 원칙과 면접 방법들을 정리해본다.

우선 내가 생각하는 채용의 대원칙을 한 마디로 정리하면, 장점이 뚜렷한 사람이다. 현재의 팀에 부족한 장점을 갖고 있으면 더더욱 좋고, 장점이 많으면 더 좋다. 하지만 약한 장점이 여러 개인 사람보다는 하나의 장점이 확실한 사람을 더 선호한다. 단점은 전혀 고려하지 않는다. 정말로 단점은 고려하지 않는다. 아, 물론 흉악 범죄를 저지를 것 같은 사람이라거나 그러면 안되겠지만, 그런 사람은 한 번도 면접에서 본 적이 없기 때문에 별로 생각할 필요 없다.

단점을 고려하지 않는 이유는 고려할 필요가 없기 때문이다. 팀의 성과는 개개인의 장점이 모여서 나오는 것이다. 개개인의 단점은 팀이 보완하면 된다. 세 명 이상 모인 팀에서 개개인의 단점을 보완 못할 상황은 거의 발생하지 않는다. 만약 팀을 이끄는 팀장이 명확하게 있는 상황이라면 개개인의 단점을 보완하는 것은 팀장의 책임이다. 나는 내가 팀장이면 다른 사람의 단점이 뭐든 보완할 자신이 있기 때문에 자신 있게 장점이 뛰어난 사람을 뽑는다. 나는 운이 좋아서 늘 좋은 팀원만 만나왔다고 생각할 수도 있겠지만, 난 충분히 일반화해도 좋을 만큼 대부분의 단점이 별 것 아니라고 생각한다.

물론 나 역시 단점이 아주 뚜렷하고 단점의 종류도 여러 가지다. 하지만 나 자신에게도 같은 기준이 적용된다. 난 내 단점을 극복하기 위한 노력은 전혀 하지 않는다. 내 노력은 내 장점을 강화하는데 집중된다. 단점에 관해 내가 하는 노력은 단 두 가지. 늘 내 단점을 보완해줄 수 있는 사람이 있는 팀에서 일하려고 하는 것. 그리고 내 단점을 커버할 수 있는 시스템을 만드려고 노력하는 것. 나 뿐 아니라 난 내 팀원들이 다 장점을 강화하기 위한 노력을 더 많이 했으면 좋겠다.

장점이 뚜렷한 사람을 뽑는 것이 목표라면 채용 과정은 장점을 발견하는 과정이다. 장점의 발견은 서류 전형에서부터 시작되지만, 아직 서류에서 걸러야 할 정도로 지원자가 많은 상황은 별로 겪어본 적이 없어서 눈에 띄는 점 하나만 있으면 대부분 서류 전형은 합격이었다. 정말 중요한 건 면접에서 장점을 발견하는 방법이다.

원래 이 문서는 면접에서 물어보기 좋은 질문들을 정리하기 위한 용도로 시작했다. 하지만, 여러 번 채용 면접을 하다보니 사전에 정해진 질문은 의미가 없었다. 중요한 건 그 질문에 대한 답을 듣고 두번째, 세번째 깊이 파고드는 질문을 하는 것이다. 간혹 보면 유용한 면접 질문으로 널리 퍼져 있는 질문을 기계적으로 하는 경우를 본다. 이를테면 이런 것들이다.

• 가장 최근에 읽은 책은 무엇인가요?
• 개발자 커뮤니티에서 활동을 하시나요?
• 집에서 취미로 개발을 하나요?

질문 자체는 나쁘지 않다. 첫번째 질문도 "자기 계발을 열심히 하시나요?" 같은 질문에 비하면 좀더 구체적인 답을 이끌어내기 좋은 질문이다. 하지만, 이 질문의 한계는 닫힌 질문이라는 것이다. 닫힌 질문은 뭐고 그럼 열린 질문은 뭔가? 닫힌 질문은 알고 싶은 정보가 정해져 있는 상태에서 던지는 질문이다. 첫번째 질문은 이 개발자가 공부를 열심히 하는 사람인지 아닌지 알기 위해서 던진 질문이다. 하지만 이 질문으로 정말 이 개발자가 공부를 열심히 하는지 아닌지 알 수 있을까? 공부를 하는 방식은 여러 가지가 있다. 책은 이미 낡았다고 생각해서 전혀 안 읽지만 인터넷에서 문서를 열심히 찾아보면서 직접 실험해보는 개발자는 어떨까? 혹은 각종 논문을 열심히 탐독하는 개발자는? 코드가 최고라고 생각해서 오픈소스 코드를 깊이 파고드는 개발자는? 이처럼 다양한 공부 스타일이 있는데, 후보자가 공부를 열심히 하는지 아닌지 알기 위해서 이 모든 가능성에 대해 질문을 던질 것인가?

물론 닫힌 질문도 좀더 잘할 수는 있다. 이를테면 이렇게 해볼 수 있다.

• Q: 기술적인 공부를 많이 하는 편인가요?
• A: 네.
• Q: 그럼 최근에 어떤 공부를 했었는지 말씀해주실 수 있나요?
• A: 최근에 실용주의 사고와 학습을 읽었습니다.
• Q: 그게 언제였나요?
• A: 재..재작년이군요.
• Q: 최근에 다른 건 없었나요?
• A: 아, 지난 주에 Dynamo 관련 논문을 하나 읽었네요.
• Q: 그 논문을 간단히 요약해서 말씀해주실 수 있나요?

이런 식이면 공부하는 스타일인지 아닌지 좀더 파고들어볼 수는 있다. 그런데, 만약 공부는 별로 열심히 하지 않지만, 데이터베이스 성능 튜닝을 기가 막히게 해내는 사람이라면 어떨까? 장점은 수십 수백가지가 있다. 닫힌 질문은 말하자면 수십 수백 가지의 장점의 리스트를 뽑아놓고 하나씩 물어보면서 체크 표시를 하는, 그런 방식이다. 물론 이렇게 세상에 존재하는 개발자의 모든 장점을 체크해볼 수 있으면 더할 나위 없이 좋겠지만, 우리의 면접 시간은 제한되어 있다. 그래서 나는 확인할 장점의 리스트를 미리 가지고 가지 않는다.

그보다 더 좋은 방법은 열린 질문을 하는 것이다. 열린 질문이라고 해서 엄청 고급스러운 질문이 아니라, 그냥 특정한 답을 기대하지 않고 그 사람의 경험을 더 깊이 끄집어낼 수 있는 질문이다.

개발자 면접할 때 참고할 내용들 정리

평가 요소

• 학습 능력
• 실제 코딩 실력
• 논리적인 사고력
• 문제 해결 능력
• 기술적인 경험의 깊이
• 자기 개선 노력
• 끈기

실마리를 찾기 위한 질문